Subject: flow control ACKs

From: "Peter W. Gayek" <[email-masked]>
Date: Mon, 18 Sep 95 15:13:56 EDT

I thought I would post a short note to document one issue raised at
AIW8 that might affect interoperability.  I know Paul took notes on
some of these items but they were too low-level for the overall minutes.

The first sentence of section 8.4 "Acknowledging a Flow Control
Operator" reads:
 "Each sender must acknowledge each FCIND with an FCACK which is
  piggy-backed on the next frame in the opposite direction in all
  cases except the Reset Window Operator."

Once a circuit is up, the "next frame in the opposite direction" is
almost always a DGRMFRAME or INFOFRAME.  These are the frame types
where it really matters to have the ACK, because if the grant had
reached zero this ack bit is required for the frame that carries it
to be "legal".

Someone asked:  "if the grant flowed on ICR_cs, is the ack required
to flow on the REACH_ACK, or can it wait until the first INFOFRAME
or DGRMFRAME"?  The current wording seems to require the ack on the
REACH_ACK, but some may have assumed it meant the first INFO/DGRM.
The wording should probably be improved in any case, because the
"next frame" could in fact be TEST_CIRCUIT_REQ, which we have agreed
cannot carry FCI/FCA/FCO.

I suggest that before the DLSw Interoperability Test, everyone make
their code as forgiving as possible;  don't kill the circuit if
the other guy skips REACH_ACK and uses INFOFRAME.  Likewise, don't
choke if the guy uses REACH_ACK.  Then we can get through the test
and worry about the wording at AIW9.

Any other thoughts out there?

Peter Gayek
IBM Corp.